Transcript
[0:00] Also beim erfinden dieser welt von grund auf neu da muss man eben dann auch sehr gut drin sein aber das ist ja sozusagen ein fehler in der umsetzung des paradigmas und nicht so sehr ein systemischer fehler in dem paradigma selber.
Wir sehenden nehmen halt dinge wahr aber vielleicht meistens auch nicht wahr.
Die andere sehr wohl wahrnehmen. Und damit ist dann so eine Aussage wie, da merkt man keinen Unterschied, auch immer schwierig, finde ich.
[0:29] Music.
[0:54] Revision 573.
[1:20] Für die Unterstützung und fürs weitere Zuhören. Wir wären heute zu zweit.
Revision 573: Glücksrad (Events, Bluetooth, Forms, Titles, Mask-Borders, attr-Funktion)
[1:30] Da hätten wir aus dem Team einmal den Peter. Moin, moin.
Und ich bin der Shep. Das heißt, wir haben heute keinen Gast.
Und das eröffnet uns die Möglichkeit, mal wieder nach längerer Zeit Glücksrad zu spielen.
Yay! Juhu! Wir haben in der Vorbesprechung schon wieder von Hölzchen auf Stöckchen gekommen und haben aber versäumt, die aufzunehmen.
Das wäre auch schon so ein halbes Glücksrad geworden, wahrscheinlich.
Ja, aber ich hab auch hunderte Dinge über...
Film gesagt, dass das auch ja genau. Das heißt also. Wir starten jetzt gleich mal mit mit dem unserem Zufallsgenerator.
Da gehen wir mal auf working draft. Die Slash Glücksrad könnt ihr auch drauf schauen, ist als per Websockets verbunden, sodass der Peter sieht, was ich mache und umgekehrt.
Ich habe das Glücksrad auch eben noch aktualisiert, um die neuesten MDN Daten, sodass wir auch wirklich auf dem neuesten Stand sind.
Was mögliche APIs und Web-Technologien angeht, die der Zufallsgenerator da rausfischt.
Genau, und dann hoffen wir einfach nur, dass wir nicht zu viele bekommen, die wir schon mal irgendwann hatten.
[2:45] Ja, oder zu viele zu neue Sachen, über die wir gar nichts wissen.
Oder so. Wobei mir das persönlich fast lieber wäre als umgekehrt.
Ah, muss ja wenigstens einer von uns beiden Nachwirkungen von irgendwas haben.
Und wenn das jetzt wieder irgendwie so die Audio-Panel-Note ist, Audio-Panner hört sich auch gut an, auf jeden Fall. Alles klar, hast du Lust, das erste Mal hier den ersten Knopfdruck zu tätigen? Ich klicke jetzt auf den Button Zufallsgenerator aktivieren. Drei, zwei, eins und wir reden jetzt über… man glaubt es kaum.
Oh. Oh. Hä.
Event/type
[3:21] Wir haben drei mögliche Kapitel. Ich glaub, das eine ist HTML-Elemente, CSS und quasi Browser-APIs.
Wir sind jetzt bei API gelandet und da dann im Zweig Events und da in der Property Type.
Und bei Events waren wir ja tatsächlich schon in unserer rausgeschnittenen Vorbesprechung.
Genau, dann können wir da ja einmal kurz noch das wieder einstreuen später, was uns dadurch im Kopf ging.
Aber bevor wir das machen, können wir einmal kurz erklären, was es denn hier überhaupt mit diesem Type auf sich hat.
Wahrscheinlich selbsterklärend, ne? Weißt du nicht? Probier doch mal, und dann sag ich dir, ob das die gute Selbsterklärung war.
[3:58] Ja. Genau, also der Type, wenn der Event-Listener an den Event-Händler übergibt, dann bekommt der Event-Händler ja automatisch das Event und also als Parameter mitgegeben.
Und das hat eben eine Type-Property, und die wiederum enthält einen String, der der gleiche ist wie eben, wo man den Add-Event-Listener draufgesetzt hat, also zum Beispiel Klick.
Und, äh, genau, nutzen kann man das, wenn man vielleicht einen, einen und denselben Event-Händler benutzt für verschiedene Event-Listener, die man aufschaltet.
Und wenn man dann in der Verarbeitung Dinge vielleicht, äh, abhängig machen möchte vom Type, dann hat man irgendwie sein Code nicht mehrfach geschrieben und hat aber trotzdem die Möglichkeit, noch mal flexibel drauf einzugehen.
Ja, und man muss sich natürlich vergegenwärtigen, was so ein Type sein soll, wenn man sich sein eigenes Event bastelt.
Also Class CustomEvent, ExtentsEvent, okay.
Man sollte es nicht CustomEvent nennen, weil CustomEvent ist ja wieder was Eigenes.
Aber wenn man sich so eine eigene Eventklasse herleitet, muss man sich auch überlegen, was sollte dieses Ding für ein Type haben.
Weil der String ist letztlich der Mechanismus, mit dem man ja sagen kann, mir werden drei Eventobjekte gegeben, Was auch immer.
[5:18] Ja. Genau, und das machst du aber dann beim Definieren dieses Custom Events, dass du diesen Type dann sozusagen da rein verdrehtest, und dann kannst du aber ja wieder ganz klassisch mit AddEventListener und als ersten Parameter dann als String diesen String, nutzen und bei diesen Events dann quasi triggern, bei diesen Custom-Events, die du zum Beispiel Working Draft Doppelpunkt-Event nennen könntest.
Genau, das könnte man machen. Mhm. Ich würd an der Stelle nur eventuell sagen, ich glaub, Custom-Event, also den Constructor, New Custom-Event, den sollte man wahrscheinlich nicht mehr benutzen.
Der ist deprecated, ne?
Also, wie ist das, was benutzt man mittlerweile? Ich weiß es gar nicht. Also, ich muss das immer nachgucken.
Ich weiß gar nicht, ob der deprecated ist. Bei MDN ist das nicht als deprecated markiert.
Okay. Irgendwas ist auf jeden Fall deprecated in diesem Custom-Event-Universum.
Vielleicht ist das auch eine alte IE-Variante gewesen oder so.
Das kann natürlich sein. Das initCustomEvent-Funktionchen, das ist, glaube ich, deprecated. Mhm.
Aber von allem supported außer Dino, von daher kann man das machen.
[6:30] Und die Alternative wäre natürlich, Classes zu verwenden, Dass man sich eine eigene Event-Klasse baut, mit einem eigenen Constructor, die dann den Type festlegt und sich so ein Custom-Event herleitet, sodass man nicht diese extra Event-Klasse mit irgendwelchen dynamischen Properties, also diesem Details-Ding, verwenden muss, sondern macht man am besten einfach, indem man wirklich Class A extends B mit Events macht.
Deswegen nur beim Begriff Custom-Event aufpassen, dass wir damit ein Custom-Event, aber nicht den Custom-Event-Constructor meinen.
Ja, und sag noch mal was zu den Use-Cases von Custom-Events.
Ja, man will ein Custom-Event haben, ne? Also, man könnte ja zum Beispiel hingehen und könnte sich irgendwie überlegen, überleg, eine Web-Component bauen, die irgendwelche Interaktionsmöglichkeiten bietet und die soll halt ein Custom-Event dispatchen.
Oder man baut sich irgendeine Art von Do-It-Yourself-Message-Bus auf und hat irgendwie so, sagt irgendwie, ich wickel die Kommunikation, was so meinen Applikationsdatenfluss angeht, einfach darüber ab, dass ich irgendwelche Events auf das Dokument schmeiße zum Beispiel, und da hänge ich einen Listener drauf, der dann diese ganzen Events einsammelt und sich am Type entscheidet, entscheidet, aha, das ist jetzt ein Datenupdate und das muss ich jetzt so und so verarbeiten, indem ich was mit HTTP-Request wegspeichere oder in die Datenbank schreibe, Sowas in der Richtung.
[7:41] Ja, genau. Also, ja, man kann ja auch Custom-Events triggern, die quasi so heißen, also, man könnte zum Beispiel ein künstliches Load-Event auch feuern.
Also, man kann da quasi sich an dem Namensraum auch halten, den es schon gibt. Also, man müsste jetzt, und dann würden die gleichen Event-Listener funktionieren, wenn man das Event entsprechend kompatibel irgendwie aufbaut.
Ja, das ist natürlich ein großes Wenn, ne? Also, weil ich meine, die unterschiedlichen Event-Klassen in Anführungszeichen haben ja wirklich unterschiedliche Properties.
Und wenn man so was sozusagen faken möchte, ein Load-Event faken möchte und überzeugend faken möchte, muss man halt eben zuschauen, dass man das auch wirklich komplett implementiert bekommt.
Ich bin jetzt in den Details der einzelnen Events gar nicht mal so bewandert.
Wahrscheinlich ist da relativ wenig Magie drin. alles abfragt von diesem Event, also beim Load-Event ja meistens relativ wenig. Aber ich könnte mir vorstellen, dass du vielleicht irgendwie, wenn du sagst so, hey, ich mache einen Decoder für ein neues Bildformat und das wird in eine Canvas reingezeichnet oder so, und dann will ich irgendwie auch, dass das ein Load-Event.
[8:56] Schmeißt, wenn das fertig ist oder so.
Dann könntest du das halt machen. Ah ja, okay, das wird natürlich einiges Da muss man das auch quasi hijacken.
Ja. Aber fändest du das eine gute Idee, das Load-Event auf die Weise sozusagen zu ...
Also, okay, der konkrete Fall von deinem Custom-Image-Decoder, da ist es ja wirklich so, du baust im Prinzip einen Ersatz für das Image-Element und versuchst, das so ähnlich wie möglich zu halten. Ja. Okay.
[9:24] Bei anderen Ressourcen, die geladen werden, wär's wahrscheinlich ganz gut, sich dann was Eigenes auszudenken.
Also mein Custom, keine Ahnung, 3D-Virtual-Reality-Element, Virtual-Reality-Dings-Load-Event zu bauen für halt Dinge, die halt nicht so aussehen sollen, als wären sie Legacy-Load-Events.
Ja, ja, genau. Also wenn dann, dann nur, wenn man auch möchte, dass es dann später gleich behandelt wird wie native Dinge.
[9:53] Genau. Ich hätte noch eine Anmerkung zu dem Event Type. Hat mit Typescript zu tun.
Da ist das ja auch so, dass wenn man da einen EventListener hinzufügt und man schreibt da einfach in AddEventListener rein, das ist jetzt irgendwie ein Klick-Event, dann weiß Typescript automatisch, dass das Event-Objekt, das man im Event-Händler übergeben bekommt, ein Maus-Event ist.
Weil's ein globales Interface gibt, wo im Prinzip die Beziehung hinterlegt ist zwischen dem Type und der dazugehörigen Event-Klasse.
[10:20] Das ist ja nicht so irgendwie automatisch selbst evident, dass ein bestimmter String irgendwelche Typen bedeutet.
Aber das ist in TypeScript hinterlegt, und ich will nur erwähnen, das ist ein global definiertes Interface, und das kann man auch erweitern.
[10:33] Indem man einfach das redeklariert und dazu schreibt, yo, übrigens, mein Custom Event, auf die linke Seite von der Interface-Deklaration, und auf die rechte Seite kommt eine Referenz auf die Klasse, die das dann implementiert.
Und dann hat man diesen Benefit, dass TypeScript automatisch weiß, bei gegebenem String ist es dieses Event, ausgedehnt auf die eigenen Events auch, die eingebauten. Ja. Okay, ja, cool. Und jetzt die große Frage, die wir aus unserer Vorbesprechung noch übrig hatten. Warum babbeln eigentlich einige Events und andere nicht? Tja, genau, wir sind da nicht zu einem so vernünftigen Schluss gekommen. Also wir hatten ja als Beispiel zum Beispiel das Blur-Event babbelt nicht, während das Focus-Out-Event, was dem folgt.
[11:20] Sehr wohl bubbelt. Meine These war, das eine sind sehr alte Events, wo vielleicht irgendwie noch Uneinigkeit und Chaos und einfach, sagen wir mal, Fakten schaffen, vorgeherrscht hat bei den Browser-Herstellern, als sie diese Dinge implementiert haben. Also mit wenig Struktur und System dahinter, während andere Events vielleicht erst später das Licht der Welt erblickt haben, als vielleicht HTML5 schon da war oder die Word-WG sich hingesetzt hat und einfach mal Dinge, die im Wildwuchs waren, also nachträglich spezifiziert hat.
Aber ob dem so ist?
[12:06] Weiß man nicht. Ich kann nur den Tipp geben, wenn man trotzdem Event-Delegation, also wenn man quasi am Root horchen will auf solche Events, die nicht bubblen können, dann geht das, indem man den Event-Listener in den Capture-Mode versetzt.
Damit kriegt man jedes Event. Weil beim Capture-Mode ist es ja so, dass der quasi an der Root-Node reingeht und dann in Dombaum runterwandert bis zum Element, das quasi das Ziel ist.
Und bei diesem Herunterwandern, das ist ja die Capture-Phase, kann man eben das Event abgreifen.
Auch wenn es dann, nachdem es im Element quasi dann tatsächlich ausgelöst wurde, nicht mehr wieder zum Root hoch bubbelt.
Also, dann geht man eben hin und schneidet das mit auf dem Weg zum Zielelement.
Genau, und nicht auf dem Weg vom Zielelement, was ja so das übliche Verfahren eigentlich ist. Genau.
Und du hast gesagt, das übliche Verfahren wendest du eigentlich prinzipbedingt gar nicht an, du gehst immer direkt in den Capture-Mode.
[13:09] Genau, weil ich eigentlich nicht weiß, was ich für einen Vorteil hätte von der anderen Variante.
Genau, und ich nutze halt gerne Event-Delegation und hab dann eben meine Utility-Klasse, die ich dafür benutze.
Und die funktioniert so, dass ich eben, wenn ich irgendwie sage, so, hey, Utility-Klasse, Ich möchte gerne auf ein Klickevent horchen auf diesem Element.
Also so ähnlich wie das früher bei Jackery mit der Delegate-Methode ging.
Dann sagt halt diese Utility-Funktion so, habe ich auf dem Root für dieses Event schon einen Event-Listener?
Wenn nicht, dann wird der angelegt und dann wird vermerkt, dass ich quasi gucken soll, ob dieser Selector dann zutrifft.
Und wenn ich dann weitere, sagen wir mal, Klicks auf andere Elemente horchen will, dann sagt der, ah, cool, ich hab schon ein Klick-Event auf dem Root.
Ich erweitere einfach nur quasi die Selektor-Liste und dann test ich gegen die ab.
Und ich weiß halt dann einfach, wenn ich in den Capture-Mode standardmäßig gehe, dann ... krieg ich sie alle.
[14:20] Ja, da muss man halt nicht dieses ... Ah, kann nur wissen, was davon ist jetzt ...
Was davon bubblet jetzt und was nicht auf dem Zettel haben.
Genau, und ich glaub, früher hat man das eben nicht gemacht, weil die Capture-Phase vom IE erst ab Version 9 oder so unterstützt wurde.
Ach, genau, deswegen hat man's früher einfach eben nicht so gemacht. Mhm.
Ja, aber es ist jetzt immer noch per Default alles im Bubbling-Modus, weil es halt wegen IE 9 immer so gewesen gewesen und der Default, wenn ich ein EventListener hinzufüge, ist dann halt dieser. Und ich müsste halt Aufwand betreiben, um darunter zu kommen.
Ja, genau.
[15:03] Ja, das macht Sinn. Ich finde halt nur deine Erklärung mit so Blur vs. Focus Out, eins bubblet, nicht eins bubbelt, dass das halt irgendwie so historisch begründet ist, also kann sein.
Ich würde halt als Gegenargument aufführen, dass wir ja so was ähnliches wie Event-Bubbling haben im Kontext von Shadow DOM, nämlich Events, die composed sind oder nicht composed sind.
Composed Events sind die, die tatsächlich aus dem Shadow DOM sozusagen auch rausbubbeln für jetzt ...
Also, schlechteres Wort dafür, aber meinte ich das Gleiche, die verlassen das Shadow DOM.
Also, sind quasi von außen detektierbar, kann man sagen.
Also, man könnte quasi auf Klick horchen, und du würdest dann ein Klick-Event bekommen, dessen Target aber die gesamte, die ganze Web-Component wäre.
Und dann hast du aber die Möglichkeit, da drin noch mal in der Property nachzuschauen, Welches Element in diesem Shadow DOM wurde tatsächlich dann geklickt?
Wenn der Shadow DOM open ist, dann ja. Wenn er im Closed Mode ist, dann geht das nicht.
Ja. Dann ist das zu. Aber das Interessante ist ja eigentlich sozusagen, der scheint ja auch einigermaßen arbiträr zu sein, welche von diesen Events sind jetzt composed und welche nicht.
Und ich kann den Spezifikationen da auch keine Begründung entnehmen.
Da steht drin, dieses Event bubbelt oder nicht, dann ist das so.
Oder nicht, und dann ist das so.
Und ich persönlich hab keine Ahnung, wie das zustande kommt.
[16:32] Ja. Ja, also vielleicht wisst ihr Höherinnen und Hörer das, ob jemand dazu mal vielleicht wahrscheinlich vor langer Zeit einen Blogpost oder so geschrieben hat, dass das eben erklärt, wie es dazu kam.
Also ... ja. Wie es halt eben dazu kam, dass das halt tatsächlich als Default fest eingebaut ist, in gewisse Events.
Weil grundsätzlich zu sagen, es gibt so gewisse Events, die im Shadow DOM stattfinden, die ich verschlucken möchte, weil das ein Implementierungsdetail sein soll, das nicht nach außen propagiert wird, das seh ich ein.
Aber ich weiß nicht, warum das vom Eventtyp abhängig ist, ob das abhängig sein soll, dass es ein Implementierungsdetail ist.
Da hört's bei mir halt auf. Ja.
So ist das halt. Wir werden's irgendwann rausfinden, so wie du ja irgendwann auch gelüftet hast, wofür die XMP-Abkürzung steht.
War das ein Exempel? Ja. Ah, aha.
Ja, gut, das war relativ einfach. Da konnte ich ja in alte HTML-Spezifikationen reinschauen.
Aber ich weiß halt nicht, ob es alte Spezifikationen für altes Eventverhalten gibt.
Ja. Wir kriegen das schon noch raus. Genau, das werden wir aber, ich würde sagen, jetzt machen wir mal auf die Events den Deckel drauf. Und du bist dran, Shep.
Ja, ich drücke. Mit deinem Klick auf das Glücksrad.
BluetoothDevice/name
[17:50] Aha. Aha, hatten wir nicht vorhin auch noch darüber gesprochen, welchen Sinn hat eigentlich dieser ganze Web-Bluetooth-Kram?
Genau, und da sind wir auch gelandet, wieder in den APIs, in Bluetooth-Device und dann Name.
Und ich glaube, da brauchen wir auch nicht lange drüber diskutieren.
Das dürfte ja relativ klar sein, wofür das gut ist.
Das heißt, da kann man dann irgendwie schauen, und dann steht da wahrscheinlich so was drin wie Logitech Blablub-Maus oder so. Wobei selbst die MDN sich dazu relativ ausschweigt, würde ich sagen.
Na ja, gut, aber man kann ja die Spezifikationen angucken. Ich denke, das Problem ist halt eben auch ...
MDN schweigt sich darüber aus, im Sinne von die Beschreibung, die du vorgelesen hast, die Ad-Hoc-Übersetzung von dem englischen Text, der da drinsteht.
Aber es ist ja tatsächlich so, dass diese Bluetooth-Web-API ja letztlich bloß eine JavaScript-API ist für das, was ja Bluetooth-inherent ist.
[18:43] Und ich glaube, so Sachen wie, dass ein Bluetooth-Device einen Namen hat, Also da wohnt die Wahrheit zu, was das ist und so weiter, mehr im Bluetooth-Spezifikation.
Und die JavaScript-Variante expostet das bloß für Webentwickler.
Ja, in einer JavaScript-freundlichen Form.
Genau. Und was sollen die denn mehr sagen, als wir sind hier ein 1-zu-1-Mapping von JavaScript in die Bluetooth-API, und wir implementieren hier jetzt Sektion 7, Abschnitt C von den Spezifikationen.
Und der Bluetooth-Device-Name ist halt eben dann deren Name, ne?
Genau. Aber eben Human-Readable. Also nicht irgendwie, weiß ich nicht, so Mac-Adressen-Style, sondern schon eben Logitech MX500 oder was auch immer, die natürlich gar nicht Bluetooth ist, aber so.
Macht ja nix. Aber ich mein, das ist das Gleiche, was wir auch in unserem Telefon sehen, wenn wir uns damit irgendwie in einem Bluetooth-Device verbinden.
Also der Human Readable Name ist ein, ich nehme jetzt mal anstark, ein Bluetooth-inherentes Konzept. Ja.
[19:46] Haben wir das halt ne ja dann bist du wieder dran würde ich sagen dann bin ich wieder dran allianz kapitän blaubart und jetzt bewegen wir uns in richtung vom element
Form-Element
[19:59] okay schade schreibt du bist ja nicht so sehr in dem ganzen single page application kontext unterwegs schade also ich hatte letztens ein workshop gemacht so hat er fünf formular weil wir das irgendwo im Podcast mal erwähnt hatten in einem Nebensatz.
[20:18] Und dann meinte irgendwer sofort, wunderbar, bring meiner ganzen Firma das bei, weil wir haben da einen akuten Bedarf dran aus Gründen.
Und dabei hatte ich mir dann Gedanken gemacht, okay, diese Formularvalidierung gibt es seit Ewigkeiten und ist ja im Prinzip ein Plug-in-System, wo man an irgendwelche Inputs, Validierungsregeln dranhängen kann und da auch dann Fehler wieder rauskratzen kann, um sie irgendwo darzustellen.
Mit dann der Idee, dass so Sachen möglich wären, wie man baut allgemein ein Set von Validierungsregeln und könnte das dann verwenden in seiner React oder Angular oder was auch immer Applikation, weil es ist halt eben etwas, was nur an die native API andockt.
Und das Rendering von irgendwelchen Fehlern, das müsste halt eben tatsächlich sein, ein Job, der dann framework-spezifisch wäre, wenn man mit so was unterwegs ist.
So, und ich hab mich jetzt gefragt, ähm, event doch eigentlich der Ansatz von einer Single-Page-Application.
Der ist, ich erfinde so Frontend-Interaktionselemente, erst mal grundsätzlich komplett neu.
Also ich kann und sollte vielleicht auch so was wie ein Submit-Button tatsächlich verwenden, im Sinne eines Submit-Buttons.
Aber was ja meistens bei diesen Applikationen passiert, ist, die hijacken ja sämtliche Logik, die ein Formular normalerweise hätte.
Die machen ja keinen Post-Request, sondern die gehen halt eben hin und haben entweder den Formular-State sowieso in einem JavaScript-Objekt drin und schicken das dann irgendwohin mit einem Fetch-Request oder sowas ähnliches.
[21:42] Ich hab mich halt gefragt, sind Formulare nicht eigentlich vielleicht in dem speziellen Kontext von Single-Page-Applications, sind die überhaupt nötig?
Also, wenn wir jetzt mal so unser Webstandards-Gehirn beiseite legen, und wir sowieso sagen, wir erfinden alles neu, und das, was wir von einem Input wirklich brauchen, ist das Feature, das da ein Nutzer reintippen kann.
Und im Prinzip könnte es auch ein DivMap-Content-Editable sein, das macht ja keinen Unterschied. Aber wenn wir sowieso immer alles neu erfinden, Also ist ein Formular in solchen Kontexten ein Anti-Pattern?
Um das mal zugespitzt zu formulieren.
Hm ... Naja, wenn man alles verhindert und rausbaut, was das Formular sozusagen von Haus aus mitbringt, also wenn man das sozusagen downstript in seinen Fähigkeiten, dann könnte man das schon so sehen.
Genau, also das ... Und ich glaube, an sich ...
[22:38] Dürfte man das auch so machen, wie du gesagt hast, mit diesem Content Editable und Co.?
Das einzige Problem ist, dass die Leute das eben nicht adäquat nachbilden.
Und das bezieht sich ja vor allem dann auf die Semantik und die Interaktionsmöglichkeiten, die im Prinzip gelernt sind und die man in der gleichen Art und Weise idealerweise exposen sollte, wie das natives Formular tut.
Das ist ja eigentlich immer der Kritikpunkt an diesen ganzen Reimplementationen, wie zum Beispiel Warum ist dieser Button ein Diff oder so?
[23:21] Aber das ist ja sozusagen ein Fehler in der Umsetzung des Paradigmas und nicht so sehr ein systemischer Fehler in dem Paradigma selber.
Ja genau, also wenn man jetzt, wenn man das perfekt machen würde, wäre das legitim.
Vielleicht ist es ja auch wirklich, naja wahrscheinlich nicht, aber möglicherweise ist es sogar weniger Arbeit, das korrekt nachzubilden in den Teilen, die man nachbilden möchte, als eben das original zu nehmen und denen all die dinge dann ja abzulernen dies von haus aus mitbringt könnte sein man kämpft ja dagegen an und ich habe mir dann auch in als mir dieser gedanke kam habe ich erst mal direkt nachschauen müssen wie ist denn das dann eigentlich so umgesetzt und es gibt ja immer noch und gab ja früher da war das ja relevant dieses schöne todo.nbc.com, wo man sich ja angucken kann, wie so verschiedene Frameworks eine relativ triviale To-do-Applikation umsetzen.
Da geht's halt einfach nur darum, gib in den Input was ein, drück Enter, hast einen To-do-Punkt.
[24:22] Und da ist es tatsächlich bei vielen von diesen Implementierungen, zugegebenermaßen sind die alle steinalt und spiegeln nicht den State of the Art wieder, aber trotzdem, die haben halt kein Formular, sondern da ist halt ein Input und da ist ein Event-Listener drauf und wenn der Key-Code Enter ist, wird dieses Formular in R-Codes, was nur aus einem Input besteht, man macht keinen Unterschied, hingegangen und in Daten umgesetzt, die dann was anzeigen.
Und ich kann mir jetzt auch nicht wirklich ein Szenario vorstellen, wo das jetzt davon profitieren würde, dass es ein Formular ...
Wenn's ein Formular wäre, weil, wie du richtig gesagt hast, dann müsste man halt irgendwie so prevent-default machen, getütet wird, etc.
[24:59] Und also ich will jetzt nicht sagen dass ich wenn ich jetzt eine single page applikation bauen würde ich auf formulare verzichten würde weil ich halt eben weiß was ich alles nicht weiß und ich diese ganzen barrierefreiheit features und konsortium for free gerne mitnehmen würde.
Genau, also das ist halt das Problem, dass man nicht weiß, dass man nicht weiß.
Und wenn du das Original nimmst, dann musst du das auch nicht in dem Maße alles wissen.
Aber wenn du das eben tust so, also mit großer Macht kommt halt große Verantwortung.
Und dann müsstest du dich in all diesen Bereichen auskennen.
Also ich weiß zum Beispiel nicht, ob es irgendwelche assistiven Technologien gibt.
Das müssen ja nicht nur Screenreader sein. Das können ja auch irgendwie Bildschirmvergrößernde Geschichten sein, wo man irgendwie dann mit anderen Methoden als mit einer Maus, zum Beispiel gibt es ja auch dieses, dass der Bildschirm so in Bereiche unterteilt wird und dann, also für Leute, die sich halt so gut wie gar nicht mehr bewegen können und die können dann zum Beispiel, dann hast du so ein Ding, was von links nach rechts geht und dann klimperst du mit einem Auge, dann bleibt der in der Horizontalen stehen, und dann macht er das gleich noch mal in der Vertikalen, dann klimperst du wieder mit dem Auge, und dann ist dein Cursor an einer gewissen Stelle.
[26:16] Also, es gibt ja alle möglichen Sachen. Ich weiß halt nicht, ob das damit funktioniert.
Und dadurch, dass ich's halt nicht weiß, ich aber mich eher drauf verlassen kann, dass native Elemente da supported werden, würd ich halt immer auf die gehen.
Aber grundsätzlich würd ich dir recht geben.
Naja, und grundsätzlich würd ich auch sagen, wenn wir jetzt davon ausgehen, dass die Leute ein Input-Element verwenden in so einer Single-Page-Applikation, auch das, glaube ich, eine Annahme ist, die nicht unbedingt hält, wenn man mit irgendwelchen Design-System-Libraries hantiert.
Da macht man sich ja in React kein Input hin, sondern irgendwie ein...
[26:49] Keine Ahnung, Material-UI-Input oder so ein Krempel. Ich kenn mich mit den Details nicht aus, was es da so alles gibt.
Aber die Leute und auch die Entwickler von Designsystemen wollen ja ganz gerne haben, dass es die Möglichkeit gibt, eine Komponente irgendwo reinzupflanzen, die nicht nur ein Input ist, sondern auch sämtliche Styling-Regeln und JavaScript-Event-Händler und so mit sich bringt.
Und dass sozusagen die, die am Ende tatsächlich ein Formular, real oder konzeptionell, bauen, die komponieren ja bloß vergleichsweise highlevelige Komponenten öfter mal. Die hantieren nicht mit Input, sondern die hantieren mit Rappern, die irgendwas rappen, was gegebenenfalls ein Input enthält. Aber ich frage mich halt eben, ob sozusagen die sich alle damit einen Gefallen tun, wenn sie wirklich ernsthaft Formulare verwenden, oder ob das im besten Fall egal und im schlimmsten Fall ein aktives Hindernis ist, wenn sie sowieso sagen, wir erfinden die Welt von Grund auf neu. Ja, ja genau. Aber man muss halt trotzdem, trotzdem also beim erfinden dieser welt von grund auf neu da muss man eben dann auch sehr gut drin sein so wenn man das ist, also wenn man jetzt unterstellt dass die person da sehr gut drin ist und für alle fälle vorsorgt dann ja also damit steigt und fällt sozusagen diese idee eigentlich.
[28:06] Ja naja was heißt idee das ist jetzt sozusagen ein etwas ketzerischer gedanke der mir da gekommen ist ich will das jetzt nicht propagieren Aber halt eben, also, die Person muss jetzt sehr gut da drin sein, ein Formular zu beherrschen, um es reproduzieren zu können.
Dem würde ich entgegenhalten, dass eine Person auch sehr gut da drin sein muss, ein Formular zu beherrschen, wenn sie das Ding beherrschen will.
Man muss ja erst mal wissen, dass so was wie ein Event-Prevent-Default dazu führt, dass das Ding nicht abgeschickt wird.
Und wie hantiere ich mit diesen Validierungsfehlern, die dann ja aufkommen, in jedem Browser anders sind, in jedem Browser anders aussehen, alle kacke sind oder so.
[28:41] Ja, das stimmt. Wenn man dann sagt, okay, ich nehm mir halt diese Komponentenlibrary, die das alles für mich schon mal irgendwie in geordnete Bahnen lenkt, die zumindest überall gleich aussehen, dann frag ich mich, also, ich weiß halt nicht, ob in denen noch Formelemente vorkommen.
Aber ich weiß halt auch nicht, ob das einen Unterschied macht oder ob das relevant wäre.
Und ob das einfach nur so mein standardsbefolgendes Gehirn ist, das da sagt, ah, ein Formular, da muss das allererste Schritt halt eben sein, ein Formelement.
Ja genau, das ist so, da sind wir natürlich irgendwie drauf getrimmt und geeicht, dass das irgendwie, dass das selbstverständlich ist.
Da muss man sich vielleicht irgendwie, weiß nicht, also da könnte man auch anders rangehen an die Sache.
Also ob man das tun sollte, weiß ich nicht. nicht. Also vielleicht gibt es ja jemanden in der Hörerschaft, der diesen Ansatz eben gegangen ist und uns da irgendwie vielleicht im Community Slack oder auf einem der zwei sozialen Netzwerken berichten kann, wie es ihr oder ihm damit ging.
[29:51] Ja oder ob man als nutzer oder nutzerin einer solchen library überhaupt weiß ob da formelemente am start sind.
Ich glaube ja auch ein indiz wenn man es wenn man es nicht mit kriegt oder es nicht wahrnehmbar ist dass da welche sind ist ja auch egal.
Ja ja gut aber das ist natürlich immer die also hat man dann alle perspektiven die der wahrnehmbarkeit da unter einem hut weil wir sehenden nehmen halt dinge.
Nicht wahr oder wahr, aber vielleicht meistens auch nicht wahr, die andere sehr wohl wahrnehmen.
Und damit ist dann so eine Aussage wie, da merkt man keinen Unterschied, auch immer schwierig, find ich.
Aber ich ...
Ich wollte jetzt explizit die rücksichtslose Developer-Perspektive einnehmen, den idealtypischen rücksichtslosen Single-Page-Application-Otto.
[30:41] Der sagt, ich hau das jetzt raus, mir egal, Hauptsache, es ist irgendwie fancy und TypeScript.
Weißt du? Wie gesagt, ich hab halt hier auf der einen Seite, meines mein mein mein paradigma so dass ich jetzt mal so tolles postuliere und auf der anderen seite die vielen dinge die in der umsetzung.
Das paradigmas schief gehen können da bin ich 100 bei dir wie ich auch schon sagte wenn ich ein formular baue mache ich das weil ich weiß was ich nicht weiß aber wenn ich nicht weiß was ich nicht weiß.
Und ich sozusagen einfach nur dieser ideologie folge die da sagt wir erfinden alles von grund auf neu innerhalb dieses dieses denkrahmens.
Ja. Ist ein Formelement glaub ich egal. Das ist nur, was ich sagen wollte, nicht, dass das alles wirklich egal ist.
Ja, also man guckt halt erstmal, dass man die Probleme, die einem am nächsten sind, erstmal beiseite schafft.
Und wenn der Chef da steht und sagt, hier mach ein Formular, das irgendwie per Ajax da und da hingeht, mit, weiß ich nicht, vielleicht noch Formularvalidierung oder so, dann muss man dafür schon einiges wissen.
Und genau, der Chef ist der, der einen zusammenscheißt.
Die Benutzer sind eben irgendwie, sind einem ferner.
Und man hat auch keinen, die stehen nicht in der Bürotür und machen einen Rund.
Und dann kann ich das schon verstehen, dass man vielleicht erst mal den Haken dran macht.
[31:58] Und die anderen Probleme irgendwie gar nicht erst recherchiert, die dann entstehen können.
Und auch nichts von denen weiß eigentlich. Und überhaupt ja auch zurecht sagt, die Probleme sind ja dann auch so ein bisschen in der Verantwortung derer, die mir die High-Level-Komponenten bieten.
Also, wo ich halt eben so mein gestaltetes, fertiges, vorkonfektioniertes Input irgendwo einbaue, da könnten die sich ja auch drum kümmern.
Das wäre ja eigentlich deren Job, wenn die sagen, das ist die eine Komponente, sie alle zu knechten.
Genau, das steht ja dann auch bei den meisten Frameworks, dass die tiny und blazing fast sind und accessible natürlich.
Und easy to style, und eigentlich ist ja auch dann alles cool.
Genau. Und inwiefern das dann stimmt? Nööö.
[32:41] Genau. Aber das, äh, genau, findet man selber dann ja meistens selber ...
Also, selber findet man das dann oft ja gar nicht raus. zu tun.
Okay, das war jedenfalls so meine kätzerische Formularidee, hast du eine kätzerische Formularidee?
Eigentlich nicht, außer dass Formulare, also kätzerisch nicht, ich, Formulare sind auf jeden Fall immer ein großer, sagen wir mal, arbeitsintensiver Baustein, finde ich, in Komponentenbibliotheken, also, und dann, also, Wenn man denn, wenn man nichts Fertiges nimmt, also wenn man das selber baut, und da steckt dann schon einiges so an Dingen drin.
[33:27] Was so auch Layoutbarkeit angeht. Und eben, wie macht man das mit der Validierung?
Wo blendet man die ein?
Ja. Was halt eben alles Fragen sind, die man sich nicht stellen muss, wenn man einfach sagt, ich outsource das UI-Problem, was von irgendwelchen Leuten installiere und ich hoffe, die Breaking Changes passieren erst, wenn ich mich darum nicht mehr kümmern muss. Ja, ja dann. Okay, dann soll ich noch einen Zufallsgenerator-Klick wagen? Ja, gerne. Okay, drei, zwei, eins. Wir haben jetzt hier das Title-Element.
Title-Element
[34:08] Hehe. Tja.
[34:14] Vielleicht kann man da erstmal anmerken, dass das ein Element ist, wo du glaube ich auch keine anderen Elemente hineinstecken darfst. Die darfst du nur mit Text befüllen, richtig?
Richtig. Das ist ja auch was, wo man denken könnte, hey, warum kann ich denn nicht inline formatieren, auf irgendeine Art und Weise. Das wäre doch auch cool.
Ähm, tja, geht aber nicht, weil steckt im Head und wird ja dann quasi gemappt auf ein Tab oder irgendwie sowas. Und die sind dafür nicht eingerichtet.
[34:55] Das stimmt. Man kann die Farbeigens irgendwie animieren und alles, aber der Title ist der Titel.
Genau. Und sonst gibt's irgendwelche Attribute, da draufsetzen könnte und wollte, vielleicht Lang könnte ich mir vorstellen, aber, im Grunde würde das wahrscheinlich eher meistens so sein, dass man die Lang ja aufs Root-Element setzt und das ganze Dokument in der Sprache deklariert und dann sollte der Title natürlich auch tendenziell eher der Sprache folgen, die das Gesamtdokument hat. Du könntest ein deutsches Blogpost machen, wo du einen einen englischen Titel irgendwie oder einen englischen Fachbegriff im Titel hast, so.
Genau, oder dein User Interface ist einfach so, du bist ein PDF-Reader und du lädst ein englisches PDF mit einem englischen Titel in so ein Chrome rein, nur ein paar Buttons hat, aber das ist ein deutsch-lokalisierter PDF-Reader-Apparat, aber nur mit dem Titel von dem PDF im Titel darstellen.
[35:50] Also, das hielt sich jetzt nicht für so abwegig. So, jetzt hab ich auch endlich in der Spezifikation das Title-Element gefunden.
Content-Attribute, globale Attribute und da ist die Language auch mit drin, genau.
Genau, und das bedeutet, also die Tatsache, dass du keine Elemente im Title verwenden kannst, heißt auch, dass du sowas nicht machen könntest, wie ich möchte ein Wort als englisch labeln, damit das vielleicht bei der Aussprache korrekt ausgesprochen wird oder so. Aber das sind letztlich, würde ich sagen, so Luxusprobleme. Naja, weiß ich nicht, so luxusproblematisch vielleicht nicht, wenn du halt irgendwie hier so der fancy Business German bist, der irgendwie sich ein Start-up gebaut hat mit einem tollen englischen Titel.
[36:43] Aber deine Kunden sind irgendwie deutschsprachige KMU, dann ist deine Dokumentation zum Benutzen des, keine Ahnung, Kundennummern-Widgets halt auf Deutsch.
Aber wenn dein Produkttitel dann Fancypants UI ist, wie wird das ausgesprochen vom Screenreader?
Da hast du ja nur die Wahl zwischen Pest und Cholera. es ja auch so ist, ich glaube, der, ich weiß nicht, ob der Marco C. uns das mal gesagt hat, dass es auch nicht unbedingt angenehm ist, wenn die Screenreader sozusagen ständig die Vorlesesprache wechseln. Also, dass man den Leuten damit auch nicht immer Gutes tut, sag ich mal, wenn man da sehr akribisch die Sachen auszeichnet, als das ist jetzt Englisch, Das ist jetzt wieder Deutsch, das ist wieder Englisch.
Ähm, genau. Weil?
[37:37] Ist einfach eine scheiß User Experience. Warum? Keine Ahnung, vielleicht dauert der Wechsel lange hin und her.
Ich wollt grad sagen, du hast grad den Satz gesagt, das ist eine scheiß User Experience.
Aber ich persönlich finde nicht, dass der Satz eine scheiß User Experience ist, obwohl da lang die Sprachen gemischt werden.
Ja, das ist natürlich ... Oh, jetzt sind wir, äh, genau ...
Jetzt, äh, genau, betreten wir die Matrix.
Hahaha. Ähm, ja, keine Ahnung, also, ähm ...
Vielleicht habt ihr Hörer da auch noch, ähm, Input, wie das aussieht, oder nutzt ihr Screenreader und könnt sagen, was daran noch mal nicht so cool war?
Ja, ich meine, vielleicht ist das ja einfach eine Limitierung irgendwie der Software.
Weißt du, du hast irgendwie die Stimme von Sprecherin 1 für Deutsch und die Stimme von Sprecherin 2 für Englisch.
Und das ist noch nicht so eine komplett synthetisierte Siri-Geschichte. Das wäre natürlich extrem irritierend.
Definitiv. Ja, das macht Sinn. Und genau, ansonsten, was fiel mir noch ein?
Ach ja, genau, ich wollte noch ...
Ich hatte noch grad den Gedanken, dadurch, dass man ja keine Elemente verwenden kann in TITLE.
[38:52] Könnte man ja auch denken, dass vielleicht bestimmte Entitäten gar nicht kodiert werden müssten, die normalerweise in HTML kodiert sein müssen, wie zum Beispiel kleiner, größer oder eckige Klammern quasi.
Genau, aber da können wir auch direkt mal hier in dem MDN gucken, denn im Title ist das Title-Element mit eckigen Klammern.
Und jetzt schaue ich mal, wie das im Quelltext hinterlegt ist, ob das entitätskodiert ist oder nicht.
Und, und, und, wo ist das Title-Element?
Ist ja hier minifiziertes... Das ist kodiert. Das ist kodiert.
Tja, aber könnte, also weil der Sinn und Zweck der Kodierung ist ja irgendwie hinfällig, dementsprechend könnte ich mir vorstellen, dass das vielleicht hier auch funktioniert oder nicht nötig ist.
Funktionieren tut's ja sowieso immer.
Ja, naja, du darfst ja nicht vergessen, nur weil du was in HTML nicht schreiben darfst, heißt das ja nicht, dass es nicht geht.
[40:05] Ja, genau. Die Frage ist ja, was macht der Parser? Deswegen schaffe ich jetzt hier gerade mal ein kleines Experiment.
Kann ich jetzt nicht erkennen, weil ich zu viele Tabs offen habe.
Äh, ja, ne, also der ist jetzt auch bei meinem nicht-codierten Input in den Title in der Lage, das korrekt darzustellen.
Mhm. Und meint jetzt nicht mehr, da ein P-Element reinzubauen.
Muss also schon auf PASA-Ebene ausgeschlossen sein, dass dieses Zeug da als HTML-Tag verarbeitet wird.
Was ja auch aus der Definition vom Content in den Spezifikationen so ein bisschen hervorgeht, weil er halt eben sagt, da steht Text drin ohne Intra-Element-Whitespace, und das impliziert ja, dass diese spezielle Form von Whitespace zwischen Elementen da nicht drin existieren kann.
Was ist, wenn du ein schließendes Tag da reinschreiben würdest von irgendwas, was würde dann passieren?
Weil ein schließendes Title, Das ist ja das einzige, was er erkennen würde.
Wenn ich jetzt ein schließendes P reinmache, ohne öffnendes P, dann kriege ich es auch korrekt angezeichnet. Mit öffnendem P ist es dann auch sichtbar.
Spitzklammer auf P, Spitzklammer zu und die Variante mit Slash genauso.
Okay.
[41:08] All right, genau. Und dann gibt's noch das SVG-Element, das ist ein Title-Element, oder die SVG kann auch ein Title-Element beinhalten.
Die findet man ja auch immer in den, glaube ich, in den Exporten von Adobe Illustrator und Co.
Genau, die werfe ich aber meistens raus, weil ich die, ich glaube, wenn man die Inline in HTML reinpackt, dann, Genau, also dann mache ich lieber ein Aria-Label auf das SVG-Root drauf oder sowas.
Oder ist es eben sowieso nur Dekoration und dann will ich keinen Titel haben.
Es gibt ja zwei Möglichkeiten. Ist es Dekoration, dann ist dir das egal.
Oder es ist irgendwie was, was beschildert werden muss. Und dann ist ja eigentlich so diese Fick-Caption-Geschichte das Mittel der Wahl, oder?
Ja, genau, das sollte man sowieso viel öfter benutzen, Figur und Caption.
Ja, ist eigentlich totaler No-Brainer, aber ... Genau, kannst du ja auch für andere Sachen als Bilder benutzen.
Für Videos.
[42:14] Ja. Genau. Jo. Ich hätte sonst zum Title-Element noch so zwei Fun-Facts.
Ja. Erstens, hat eine JavaScript-API.
Also, da gibt's so ein Getter, dann ist Text drauf, da kriegt man dann den Text raus.
Mhm, okay, also anstatt Text-Content, wie man das normalerweise machen würde.
Genau. Okay. Das ist aber auch so mega-Legacy wahrscheinlich, oder?
Äh, weiß ich nicht. Es ist halt da.
Also wahrscheinlich aus Dynamic ... Wie hieß das? Dynamic HTML? Nee.
DHTML, ja. DHTML, ja. Hm.
Tja, also ist halt sowohl Getter als auch Setter. Also, wenn ihr euren Title das nächste Mal updaten wollt, müsst ihr nicht in einer HTML oder so ein Kram machen, da könnt ihr einfach sagen .txt gleich irgendwas.
[42:57] Tja, das wäre Funfact 1 und Funfact 2 wäre, wenn ihr das kleinstmögliche HTML-Dokument bauen wollt, dann braucht ihr einen Doctype und einen Title Tag, also auf und zu und das war's.
Das ist so das kleinstmögliche, als gültig akzeptierte Dokument.
Damit kommt ihr durch, aber der Title ist so gesehen der einzige tatsächlich immer verpflichtende HTML-Tag.
Okay.
Ja. Naja, das finde ich auch irgendwie... Finde ich auch sinnvoll.
[43:32] Ja, weiß ich nicht. Also, ich meine, ist verpflichtend. Aber die Spezifikationen sagen auch, dass es total reasonable ist, wenn ein Dokument keinen Titel hat.
Also, der Title muss mal da sein, es muss nix drinstehen. Okay, aber steht hier nicht drin. Warte mal, was steht hier drin?
Was heißt Text that is not inter-element-wide-space? Was heißt das? Inter-element-wide-space?
Inter-element-wide-space ist ja der zwischen HTML-Text, der ja so kollabiert. Ja.
Das ist der ... Aber wie kann man denn überhaupt so einen Whitespace da reinstecken, wenn man doch sowieso keine HTML-Elemente reinstecken kann?
Du kannst das da nicht reinstecken, aber die Content-Kategorie, die hier angegeben ist, ist ja erst mal Text.
Und diese Kategorie enthält normalerweise diesen Inter-Element-Whitespace. Okay.
Und wenn wir jetzt sagen wollen, wenn man da diesen Text rausholt, weiß man, dass dieser Inter-Element-Whitespace da nicht drin ist.
Das ist ja ein Sonderfall.
Irgendwie, weiß ich nicht, ein Element.
Ja, irgendwelchen Text, und da kann halt eben auch dieser Inter-Element-Whitespace drin sein.
Das Title-Element ist diesbezüglich ja wirklich eine seltene Ausnahme.
Und deswegen ist es hier extra definiert, ansonsten hätten Sie halt eine Content-Kategorie Text ohne Inter-Element-Whitespace aufmachen müssen, ausschließlich zur Verwendung im Title-Element.
[44:46] Und statt dass man das dann halt eben nochmal extra definiert hat, hat man es hier so aufgeschrieben.
So sehe ich das jedenfalls.
Übrigens, ich habe auch noch mal hier gerade diese Text-Property, oder diesen Getter und Setter, den du eben erwähnt hast, hast du's mir angeguckt, und sehe da einen Unterschied noch zu Text-Content, und zwar bei Text-Content, da wird dir, auch wenn ja auch alle Returns und Co., die da drin stecken, äh, oder, also, Zahlenumbrüche zurückgeben.
Deswegen muss man meistens noch einen Trim draufwerfen hinterher.
Mhm. Ähm, genau, und bei Punkt Text macht er das schon dann automatisch.
Ja.
[45:25] Ja, cool. Irgendwie, genau, unnützes Wissen, aber macht Spaß.
Weiß nicht, ob es unnütz ist, also den Title updaten und den ein bisschen bequemer zu machen, ist ja schon, kann man ja machen.
Ja, oder wenn die sechste und letzte Folge rauskommt und wir wieder einen HTML-Quiz machen und das dann da drin ist, auch nicht schlecht.
Das stimmt natürlich, das darf man nicht außer Acht lassen. Siehste.
Dann genau, wir sind jetzt so 50 Minuten dran Stunde machen wir voll, würde ich sagen, oder auf jeden Fall, dann drücke ich noch mal hier.
Lasst krachen.
[46:01] Uh, wunderbar, aber richtig hier richtig fancy. Ja.
Mask-border-slice
[46:09] Genau CSS ist ja immer fancy. Genau und da geht es um eine Property namens Mask Border Slice.
Die ich noch nie benutzt habe, aber ich habe Vermutungen.
Okay, hast du denn schon mal das Konzept von einer Mask Border als so verwendet, weil Mask Border Slice ist eine Subproperty von Mask Border.
Also ich habe jetzt das noch nicht geöffnet, ich würde vermuten, es gibt doch Border-Image, gibt es doch als sozusagen Styling-Familie mit ihren, mit seinen ganzen Unterproperties und beim Maskieren verwendet man ja auch ein Bild mit, glaube ich, entweder eben Alpha-Channel oder Schwarz-Weiß-Wert.
Ich glaube, da kann man einstellen, was da sozusagen als Transparenzmaske benutzt werden soll oder nicht.
Und ich vermute, dass Mask Border Slice dann die Maskenausprägung des Border Images, ähm, also aus dem Bereich kommt.
Und jetzt sagst du ... mir, dass dem nicht so ist.
Nicht ganz so, es hat halt mit Border-Image direkt nichts zu tun.
[47:27] Sondern es ist sozusagen, man gibt eine Maske in Form von einer Grafik an.
Und dann kann man eben so justieren, wie die da gesetzt und verteilt wird, um da einen entsprechenden Effekt zu erzielen.
Okay. Also, da kannst du halt ... Sagen wir mal so, ähm ...
Wenn ich das richtig verstehe, ist das so, du hast dein Border-Image, und das ist ja wirklich das Image.
So mit Farben und alles.
Und eine Maske ist ja nur so ein Schwarz-Weiß-Ding, womit du sagen kannst, was wird ausgeschnitten, was wird angezeigt.
Du definierst dir so eine Maske und machst dir eine rote Border und schmeißt da die Maske drauf und kriegst dadurch auch zum Beispiel so ein Zick-Zack-Muster hin, wofür du normalerweise Border-Image benutzen müsstest.
Aber jetzt kannst du einfach per CSS die Border-Color austauschen, aber den gleichen Maskierungseffekt haben. Mhm, ja, okay.
Genau, und das Slicing ist dann ähnlich wie beim Border-Image auch.
Das Slicing, ja. Das sieht mir sehr verwandt aus, ja. Ja. Okay.
Firefox kann es nicht, alle anderen Browser können es. Ja, das ist wahrscheinlich so eine alte Webkit-Geschichte.
Safari 3.1, den gab es sogar noch für Windows.
Chrome ab Version 1.
[48:42] Und ja, ist ja sowieso, also außer Firefox ist ja auch alles mit Webkit-Abstammung.
Ah, jetzt habe ich endlich ist auch die Spezifikation gefunden, das CSS Masking Module Level 1.
[48:59] Genau, und aber auch anscheinend nicht in keinem der Browser.
Ist es Prefix oder nicht? Warte mal.
Ähm. Use nonstandard name, nämlich Webkit Mask Border Image.
Ah ja. Also, hat es mal wieder komplett recht.
[49:18] Genau, also es ist dann noch ... Also, ist es in den Browsern jetzt noch Prefix oder nicht?
Ja, es ist in allen Prefix, ähm, mit ja, auch dem gleichen Prefix, nämlich WebKit. Es gibt halt nur jetzt auch mittlerweile eine Spezifikation, die sagt, das soll eines Tages, wenn es mal groß ist, auch nur Masked Border heißen.
Okay, genau. Aber bis es soweit ist, dauert es. Genau, es ist also de facto ein WebKit-only-Feature, das aber auf dem Standards-Track gesetzt wurde, würde ich sagen.
Es gibt ja ein anderes, das ist dieses WebKit-Image-Set, was so eine Art quasi Picture-Element für CSS ist.
Das ist ja jetzt, also, genau, das gibt's ähnlich lange schon.
Wurde aber dann, also, da gab's dann irgendwann auch eine Spezifikation, für die aber mehr Features beschrieben hat, als die ursprüngliche Implementation.
Und genau da macht es dann natürlich Sinn, dass die ungeprefixte Version, wenn sie denn auftaucht, dann auch diesen erweiterten Funktionsumfang hat.
Und die mit Webkit-Prefix nur den alten Funktionsumfang. Also vielleicht ist das ja hier auch so, dass man sagt, hey, wenn wir da schon mal rangehen und eine Spec schreiben, dann überlegen wir vielleicht auch, ob wir noch irgendwelche Dinge fein schleifen möchten.
[50:41] Ja, man lernt ja was, wenn man es zum ersten Mal shipt. Ja, genau.
Ist ja auch dann vielleicht das eine oder andere seitdem passiert.
Das ist durchaus anzunehmen. So, wollen wir noch einen? Ja. Einen machen wir noch, okay.
Ich drücke auf den Zufallsgenerator und wir bekommen jetzt.
Attr()
[51:01] Oh, das ist gut. Weißt du, warum das gut ist?
[51:06] Weil die, die Speck dafür erweitert, also oder das wird, wird wieder daran gearbeitet. Wir reden über das, Die Attribute-Funktion von CSS.
Das ist eine großartige Kompatibilitätstabelle in MDN. So eine Zeile, wo es grün ist, und lauter Sachen, die spezifiziert sind, die aber alle rot sind in allen Browsern.
Ja, genau. Naja, die Tatsache, dass mehr Funktionen spezifiziert sind, als die Browser unterstützen, lässt hoffen, dass die da irgendwann nachziehen mit Implementierungen.
Genau, weil klassisch konntest du oder kannst du ja nur.
Den Textinhalt von Pseudo-Elementen per Attributfunktion beschicken, indem du vom Eltern-Element der Pseudo-Elemente, ein HTML-Attribut ausgelesen hast und dessen Textinhalt ist dann eben in dieses Pseudo-Element gewandert.
Und das ist bislang der einzige Use-Case.
Und was du zukünftig machen kannst, ist zum einen, dass du ähnlich wie bei Custom Properties als zweiten Parameter einen Fallback-Wert angeben kannst.
[52:30] Du kannst dann auch zukünftig diese Funktionen zum Beispiel in einem Kalk oder in anderen Dingen nutzen. Also im Prinzip wird es dann tatsächlich genutzt wie eine Custom Property.
Also eigentlich ist es eine Custom Property, die aber eben aus einem Attribut im HTML ausgelesen wird oder deren Wert da ausgelesen wird und die bekommen dann Fallback und die bekommen auch zukünftig Types, also so wie das, wie man die eben die Types definiert von CSS Custom Properties per Add Property Rule kann man dann in der Attributsfunktion auch ein Type angeben. Damit man die halt verwenden kann als Input in andere Sachen und für irgendwie, weiß ich nicht, Farbe dunkler oder heller machen.
Dazu muss CSS wissen, dass diese Zeichenkette, die da jetzt kommt, eine Farbe sein soll.
[53:23] Ja, genau. Oder du möchtest ... Du möchtest weich animieren.
Also, weiß ich nicht, warum du vielleicht ...
Die Hintergrundfarbe eines Elements im HTML-Attribut setzen willst.
Vielleicht einfach aus Developer-Experience-Gründen.
Also so Tailwind-Style.
Und du möchtest aber die Möglichkeit eröffnen, dass wenn man das HTML-Attribut auf einen anderen Farbwert ändert, dass dann eben der Hintergrund nicht einfach umspringt, sondern dass der eben weich animiert wird und das geht dann geht ja nur in wenn du dem Browser sagst so hey dieser String den du da ausgelesen hast der soll eine Farbe darstellen.
[54:11] Ja das sind das Du sagst es gerade so man weiß nicht warum wir das würde tun wollen aber es ist halt tatsächlich so, das gibt dann ja doch in diesen ganzen CSS-Engines vom Browser so viele Dinge die da irgendwie zusammenspielen, Wo man meinen würde, die müssten zusammenspielen, so ohne Problem, dass man das Atre auch woanders verwenden kann.
Aber sobald man halt ins Detail geht, wird's halt relativ schwierig.
Und vor allen Dingen, wenn man dann in die Implementierung reinschaut, wie die es halt in ihrem Browser umsetzen, sind Dinge, die halt einander komplett ähnlich aussehen, wie halt so eine CSS-Variable und so ein Atre, dann doch komplett unterschiedliche Biester.
Und nur die Developer-Experience ist einigermaßen ähnlich. Wobei ich mich jetzt irgendwie auch frage, Wenn man einfach eine Custom-Property nimmt und die mit der Attributsfunktion verdrahtet, weil die kann ja schon diese ganzen Sachen.
Die hat schon ein Fallback, die kann man typen.
Da frage ich mich, müssen diese Räder alle noch mal neu erfunden werden für diese Funktion hier?
Naja, du weißt ja nicht, ob sie neu erfunden werden müssen Oder ob die unter der Haube bei den Browsern minimal erweitert und neu verdrahtet werden müssen.
Ich meine, syntaktisch einfach neu erfunden werden. Also, unter der Haube existieren die, aber zum Beispiel eben der Type, in welchem anderen CSS-Kontext ...
Hat man das bislang, dass man den Type irgendwie als ...
[55:40] Hinten dran noch mal angibt? Leerzeichen getrennt.
[55:45] Äh, ja. Das ist halt irgendwie ein bisschen merkwürdig. Also nicht mal bei den Custom Properties macht man das, ja.
Ja, das stimmt. Aber ich meine das auch schon mal an irgendwelchen anderen CSS-Sachen gesehen zu haben.
Also das klingelt jetzt bei mir nicht unmittelbar als seltsam.
Ich weiß jetzt allerdings auch nicht, wo ich das schon mal so hatte.
Vielleicht beim CSS-Object-Model, beim Typed-Object-Model vielleicht?
Ich habe das Type-Object-Model einmal evaluiert und dann nie wieder genauer angeschaut, weil ich sofort gesehen habe, das und das und das und das und das und das geht alles nicht.
Das kann da drinnen vorgekommen sein, aber da das ja eher eine imaginäre API ist, wenn man es mal jetzt ernst nimmt, ist das ja eigentlich auch Wumpe.
Ich glaube, die ist auch verwahrlost mittlerweile, oder? Nachdem auch keiner.
[56:39] Also, der einzige Grund, warum ich mir jetzt vorstellen könnte, dass man das irgendwie so reproduziert, ist halt eben, also, man könnte den Weg halt eben auch über die Custom Properties nehmen.
Aber dann wäre ja für einen getypten Adre Einsatz einer Custom Property auch notwendig.
Und so eine Custom Property hat ja gegebenenfalls auch Nebenwirkungen, weil du ja damit theoretisch was überschreiben könntest, was weiter oben im Root oder so schon definiert wurde.
Was man halt so direkt im Adre machen kann, so in einem Durchgang ohne eine Custom Property ist ja schon, also ...
Räumt das so ein paar Probleme aus dem Weg. Ist halt so der direktere Weg.
Man muss dafür mehr Arbeit reinstecken, aber ich glaub, das fänd ich so unterm Strich schon ganz gut.
Mhm. Okay. Ja, ich, äh ...
Mal gucken, wer editiert denn diese Spec? Gibt's da wen? Äh, die, äh, Fürst Adre? Mhm.
TabAdkins und Phantasy. Genau, die üblichen.
Dann vielleicht frage ich die mal.
[57:46] Würde mich nämlich interessieren. Das können wir mal tun. Wo wir gerade schon mal beim Thema Outreach sind.
Ich kann ja nicht lustige CSS-Typ-Property-Geschichten irgendwie so ungesehen an mir vorbei scrollen lassen, ohne noch mal meinen Einfluss jetzt hier auf die Hörer ...
Ja. ... zu nutzen zu machen und zu sagen, hey, ich hab hier immer noch diesen Bug-Report mit den Keyframes in Firefox.
Der ist immer noch offen und alle paar Wochen meldet das noch irgendwer und dann wird das halt hier noch hinzugefügt von wegen Duplicate von dem Bug und dem Bug und dem Bug.
Was war das noch mal für ein Bug? Ähm ...
[58:25] Wenn man in Keyframes ... Warte mal, jetzt muss ich mal kurz gucken, dass ich das in einem Wort, in einem Satz korrekt erkläre.
Ich hab eine Animation, eine CSS-Animation mit Keyframes. Und die Keyframes setzen nicht irgendwie die Color auf Red, sondern setzen eine Custom-Property auf Red.
Und deswegen müsste sich eine Farbe verändern.
Ja. Aber das hat in allen Browsern einen Effekt, so wie man's erwarten würde, nur halt im Firefox nicht.
Mhm. Da gibt's halt einen Unterschied zwischen den normalen Properties, und den Custom-Properties, die gesetzt werden.
Der merkt das aber auch nicht, wenn die Animation dann fertig durchgelaufen ist oder so.
Der merkt's einfach gar nicht. Das ändert sich einfach nix.
Okay. Ja. Ist natürlich schlecht. Das ist suboptimal.
Und man kann sich da bei Bugzilla anmelden und man kann da mal so irgendwie sagen, ja, hier, ganz schlimm, und Daumen hoch, Daumen hoch und das sollte mal dringend repariert werden und so.
Mhm. Die sind auch nicht so edgecasig. Also, das ist was, was man eigentlich schon ...
[59:31] Haben wollte und öfters benutzt, würd ich sagen. Weiß ich nicht.
Meinst du? Also, ich finde halt, das sollte funktionieren. Es sollte keinen Unterschied geben zwischen den Custom-Properties und den eingebauten.
Aber der einzige Use-Case, den ich habe, ist tatsächlich der, dass ich, äh, ja ...
[59:51] Dinge per Animation steuern möchte, die, äh, ja, am besten von dieser indirekten Steuerung profitieren würden.
Also, ich meine ...
Ich nutze ja im Prinzip die Kaskade, um zu sagen, jetzt ist hier was fundamental anders, und ich hab viele Elemente, die darauf registriert sind, die diese Custom-Property nutzen und sich synchron updaten.
Und theoretisch könnte man ja für viele ... Ich glaub nicht, dass es so oft ist.
Ich glaub, sehr oft will man sagen, ich animiere dieses eine Teil, Ich animiere einen riesengroßen Kontext und hab riesig viel CSS, das davon abhängig ist.
[1:00:27] Ja, also, ich kann mir aber auch vorstellen, also, ähm, auf der Biontella-Rand hatte der Scott Callum einen Talk, wo der Animationen genutzt hat, um darüber Werte sozusagen mit einem Easing hin, also, zu setzen.
Der hat eben quasi eine Animation als Vehikel benutzt und konnte dann in der animation eben da die die war im grunde immer pausiert die lief gar nicht weil die eben nur sein vehikel war und mit animation delay konnte er dann eben in der animation an gewünschte stellen fahren und hat dann vom browser frei haus eine schöne interpolation bekommen je nachdem was er da eben für eine bc kurve für die animation gesetzt hat Und das wär zum Beispiel so ein Use-Case, wo du das natürlich schon wollen würdest, dass wenn du eine Custom-Property eben ...
Wenn du, äh, die mit einem Easing versehen wolltest, dann müsstest du die derzeit ja in eine Animation reinstecken mit der Technik, und dann willst du natürlich auch, dass die sich updatet.
[1:01:42] Ja, das stimmt. Ich glaub, so was Ähnliches war auch meine ursprüngliche Motivation.
Ich irgendwie was haben wollte, was funktioniert wie eine Transition. Also von Zustand A nach B ist immer ein smoother Übergang, egal was A ist. Aber da wollte ich halt eben auch die Möglichkeit von Zwischenschritten drin haben und das macht halt notwendig so eine Animation.
[1:02:05] Und um dann wirklich zu sagen, von jedem gegebenen Zustand A kann ich in ...
Also, ich hab hier eine Zustandsliste, A, B, C, D, E.
Und von jedem will ich nach E springen können.
Ja.
Aber der Schritt von zum Beispiel ... Also, wenn ich von B nach D will, dann ist halt da C zwischen.
Dann muss C auch noch mal separat angesteuert werden.
Das hat mich in die Keyframes geführt.
Ja, genau. Du könntest die Schritte in Keyframes abbilden. Du könntest da, was weiß ich, wie viele Custom Properties drin setzen, quasi, die du als Set setzt, bei 20 Prozent, bei 40 Prozent, bei 60 Prozent etc. Und dann könntest du, hättest du zum Beispiel, könntest du sagen, hey, ich, ich hab dann nochmal eine Custom Property, oder ich hab dann die Custom Properties A, B, C, D, E, F und die mappen dann einfach auf den Prozentwert der Animation, wo ich das haben will.
Und dann könntest du einfach quasi sagen so Animation.
Was war das? Animation-Delay?
Genau. Und dann sagst du, ich möchte auf B springen. Und dann mappt das eben um in 200 Millisekunden oder was.
Genau.
[1:03:18] Das war so ungefähr mein Use-Case. Am Ende hab ich eingesehen, A funktioniert nicht, nehm ich ein bisschen JavaScript und setz einfach Klassen und ...
Ne. Geht halt auch. Ist halt nicht so schön, wenn man JavaScript-Allergie hat, Ja, genau. Also ich bin ja eigentlich auch immer ein Fan von Nutze, die Möglichkeiten, die dir vorher geboten werden, bevor du dann am Ende auf JavaScript gehst.
Aber kann jeder machen, wie er will.
Und es hat halt eben auch diesen Effekt von, was wir bei den Formularen schon hatten, was wird uns alles mitgeliefert? Weil sobald du es mit JavaScript machst, hast du dann ja dieses Timing-Problem.
Dann musst du das Schalten von den Klassen von A nach B nach C ja auch sehr genau timen.
Und wenn du eine Animation hast, deklarierst du das stumpf hin.
Ja. Das ist schon ein ziemlich großer Vorteil. Ja, vielleicht könntest du das mit der Web-Animation-IPI auch hinkriegen.
Äh ... Die ... Ja, weiß ich nicht. Ähm ...
Das Fundamentalproblem ist halt ...
[1:04:24] Ich hab diese ganzen Zustände, Und ich will jeden Zustand anspringen können, aber manche Strecken haben halt eben Zwischenschritte.
Ja. Und ohne die Zwischenschritte sind Transitions super, weil einfach automatisch das interpoliert wird, egal von was zu was.
Mhm. Und man muss halt diesen Spezialfall da abdecken. Und dann muss ich ja wieder irgendwelche Keyframes definieren.
Und dann lande ich ja beim gleichen Problem wieder, dass, um das zentral irgendwie zu steuern, ich ja diese Cluster Properties im Idealfall setze.
Ja.
Wo ich ja tatsächlich meine kompletten Übergänge auch ausschließlich in JavaScript abbilden und ausschließlich in JavaScript sagen, so, du musst jetzt an die Koordinate XY fahren, wo ich das einfach hindeklarieren könnte.
Aber das haut halt nicht hin, jedenfalls nicht in Firefox. Deswegen bei dem Bug hier mal ein Sternchen verpassen.
Ich hab grad hier noch die Idee, dass du ja quasi den Animation Delay, den könntest du ja mit einer Transition versehen.
Und dann, wenn du da die Custom Properties von A nach E wechselst, dann würde er auch das Animation-Delay verschieben, weich, von eben, sagen wir mal, Null zu dem Ende deiner Animation, und dann würde das auch automatisch die Animationen quasi durchlaufen von Anfangs zum Endpunkt.
[1:05:47] Aber eben, oder von B nach D, dann würdest du nicht die ganze Animation abspielen, immer eben nur zwischen den Abschnitten hin und her gehen, die dich interessieren.
Aber dadurch, dass du quasi das Animation-Delay mit einer Transition versiehst, würde das quasi weich, führe das weich zum nächsten.
Und du würdest dann quasi, würdest dann auch, die Animation würde dann auch nicht, oder der Zustand würde dann auch nicht eben quasi ruckartig umspringen, sondern würde dann weich rüberfahren und dann durch deine Keyframes weich hindurch.
Schon cool. Okay, das würde also bedeuten, man navigiert innerhalb der ganzen Keyframes, statt das, was ich jetzt gedacht hätte. Ich habe halt eine Sequenz von Keyframes und wenn ich sozusagen jetzt das Beschreiten einer Strecke auslöse.
[1:06:44] Da muss ich noch mal in meinen genauen Use-Case reingucken, ob das tatsächlich so ohne weiteres gangbar wäre.
Das kann sein, aber ändert nix dran.
Der Bug ist da. Der Bug ist da, und der Bug muss weg. Also müssen wir da alle schön abvoten, auf dass er ernst genommen möge. Genau.
Und der wird dann natürlich auch in unseren Shownotes präsent sein, sodass ihr ihn dort anklicken könnt.
Ganz dominant.
Mit Blink-Tag und allem.
[1:07:12] Perfekt. Ja, super. Dann bleibt mir nur zu konstatieren, dass das eine sehr schöne Glücksradrunde war.
Mit im Grunde sehr schönen ...
Zufallsgenerierten Properties. Und wieder eine ganze Menge Sachen, die wir da raus mitnehmen und die wir neu gelernt haben.
Genau. Eigentlich ist das ein bisschen wie bei einer Retro. Da ist ja auch immer diese Retro-Games.
Da gibt's ja, was weiß ich wie viele. Ähm, und der Sinn und Zweck ist ja eigentlich bei all diesen Retro-Games einfach nur so ein Stichwortgeber zu sein, auf das die Leute irgendwie sich ihre Gedanken von der Seele quatschen.
Mhm. Und so ein bisschen ist das ja hier auch.
Auf jeden Fall. Das ist unsere kleine Therapiesession. Genau.
Ja, cool. Dann sag ich vielen Dank. Machen wir vielleicht, weiß ich nicht, Vielleicht nächste Woche haben wir auch wieder keinen Gast.
Da könnten wir überlegen, ob wir das auch wieder machen.
Aber das soll jetzt noch nicht entschieden werden.
[1:08:18] Genau. Und wenn ihr mal Lust habt, mit uns Glücksrad zu spielen, dann dürft ihr euch auch gerne melden.
Auf jeden Fall. Am besten in den Community-Slack oder auf Social Media.
Also auf Mastodon oder bei Space Karen einfach anquatschen.
[1:08:31] Music.
[1:08:54] Bei Blue Sky müssen wir uns auch anmelden jetzt, ne? Oder? Meinst du? Meinst du, dass das ...
24 25 26 27 28 29.
[1:09:18] Ich weiß es nicht. Also, glaubst du, das wird was? Glaubst du, das wird was? Und wenn ja, wäre es wünschenswert, dass es was wird?
Also eigentlich braucht es das ja nicht, weil es gibt ja schon Mastodon.
Und es gibt schon Twitter.
Also ich meine, das ist ja weiter da. Und das funktioniert ja für Leute, die drauf stehen können, das ja weiterhin benutzen.
Da ist ja jetzt erstmal inhärent nichts verkehrt dran.
Ja.
So. Da kann man jetzt nicht gucken, ob man irgendwie so da das aktuelle Management noch gutheißen möchte oder so.
Aber das ist ja weiter da. Und vor allen Dingen, was bringt das halt eben mehr?
Ja, also Bluestar scheint ja wirklich so was zu sein wie Twitter aber anders und Mastodon aber auch anders.
Also, wo ja schon bei Mastodon gesagt wird, das ist ein ziemlich schwaches Nr-Quotes-Produkt einfach zu sagen, wir sind genau wie Twitter nur anders, ist es ja noch schwacher, aus diesen beiden Dingern, die sich einander schon super ähnlich sind, noch eine Synthese zu schaffen.
Ja, und vor allem dann auch nicht bestehende Standards irgendwie weiterzuverwenden, die es ja gibt.
Ja gut, aber wenn du das machst, dann kriegst du ja kein Kapital.
Weil dann kannst du nicht am Ende dein Monopolisten-Game spielen.
Das ist ja schon notwendig, wenn du das so aufziehen möchtest, wie sie das probieren, das am Ende in was Geschlossenes zu überführen.
Aber das Dezentrale ist doch damit sozusagen DNA-Bestandteil, oder?
Wie kann man damit dann Geld verdienen, wenn man Dezentralität hat?
Moment, was heißt denn dezentral? Oder verdienen dann alle Geld, alle miteinander?
Dann wird auch das Geld verdient, dezentral. Was heißt dezentral?
[1:10:45] Weil, wenn du mich jetzt fragst, ist denn zum Beispiel sowas wie Amazon dezentral?
[1:10:50] Kannst du ja eine Definition von dezentral heranziehen, auf die das zutrifft?
Weil die haben ja ihre Datencenter überall rumstehen.
Und die bestehen ja aus ganzem Zweck. Vielleicht dann dezentrale Einflusssphäre.
Also ich hätte jetzt vermutet, dass...
Also Twitter ist ja auch wahrscheinlich dezentral. Technisch gesehen, ja.
Genau, aber ich glaube, in dem Fall wäre es ja so...
Oder ich seh das so wie bei Mastodon, dass irgendwie jeder ...
Äh, andocken kann mit seiner kompatiblen Instanz. Mhm.
Also, was wäre sonst die Dezentralität des Dings? Das Problem ist halt, dezentral ist irgendwie so was wie ...
Äh, keine Ahnung, äh ... fällt mir natürlich kein gutes Beispiel ein.
Aber so unabhängig oder open source oder so.
Das ist halt ein sehr schöner Begriff.
An denen du sofort eine eigene wertvorstellung andockst. aber dezentral kann ja alles mögliche sein. also du kannst ja zum beispiel sowas dezentrales haben wie eine große cryptocurrency, was ja nicht nur technisch dezentral ist, weil da irgendwie alle dran rum vorwerken an der einen blockchain. und das kann ja dann auch sozusagen prinzipbedingt dezentral sein. aber wenn trotzdem irgendwie 80 prozent von dieser kryptowährung dann einer einzigen person gehören und die damit sozusagen durchsetzen kann, was immer sie will, dann ist das trotzdem faktisch nicht dezentral.
[1:12:15] Nee, das stimmt. Das droht ja mit Mastodon auch ein Stück weit, mit diesem quasi Haupt-Mastodon-Server, der sehr viele User irgendwie auf sich vereint.
Oder guck dir E-Mail an.
E-Mail ist ... Also, dezentraler wird's nicht mehr, aber es zentralisiert sich halt eben trotzdem aufgrund von Marktkräften und Zeug. Dass du halt heute Gmail und Freenet und Microsoft und dann irgendwie noch so drei andere hast.
Und wenn du keiner von denen bist, ist es dir nicht mehr möglich, eine E-Mail zu verschicken.
[1:12:44] Ist das so? Ich weiß es gar nicht. Was ist denn, wenn die dann irgendwie ...
Was könnten die denn machen, dass man keine E-Mails mehr versenden könnte?
Na, die sortieren dich aus, wenn du halt nicht ...
Ach so, du meinst, du kannst dann diese Empfänger gegebenenfalls nicht mehr erreichen, die bei denen registriert sind.
Das System-E-Mail würde ja grundsätzlich noch funktionieren.
Ja, gut, es nützt dir aber nix, wenn's grundsätzlich noch funktionieren würde, aber keiner ist in dem Sinne verwendet.
Und deswegen bin ich da, wenn sie bei Blue Sky sagen, wir sind dezentral, bin ich, spitze ich da halt ganz doll die Ohren und frag mich so, okay, welche Art von Dezentralität meint ihr denn da genau?
Und wenn die halt eben mit dezentral meinen, sie haben ein Protokoll, das das supporten würde, und man könnte theoretisch irgendwie da viele verschiedene Server betreiben.
[1:13:30] Dann ist das nicht wirklich dezentral. Ja. Ich hab mich damit auch nicht so tiefgehend befasst, weil das ...
Ja, jetzt ist ja eh auch Invite-only, glaub ich, momentan. Und dann sollen die sich da mal alle inviten und das machen.
Auch das ist ja nicht irgendwie, wir können nicht hochskalieren.
Nee, nee, das ist ja Marketing, ja. Ja, genau.
So Clubhouse-mäßig. anfangen weißt du wenn man das schon nötig hat dann denke ich schon so gleich so kommt leute ich könnte mich genauso gut bei twitter anmelden oder bei masse dann anmelden habe ich den krampel sofort da und die versuche wenigstens nicht irgendeinen scheiß zu erzählen, aber das ist halt das playbook das aktuelle also das, diese verknappung die ist halt auch irgendwie diese strategie ja aber so als als als irgendwie selbstdenkende teilnehmer im wirtschaftssystem muss man da doch drüber stehen und muss sagen Ach, komm, Jungs, ey, nicht wirklich.
Hey, du wolltest damals auch einen Google Wave-Invite haben, glaub ich.
Ja, aber ich hab in der Zwischenzeit was dazugelernt. Ja, und Google Wave ist ja auch schon wieder kaputt.
Ja. Ja, nee, deswegen, also ich ...
Ich seh da für mich selber keine Notwendigkeit, aber ...
Ähm, genau. Ich ignorier das so lange, bis es zu groß geworden ist, um's zu ignorieren.
[1:14:51] Ganz einfach. Ja, genau, so muss man's auch machen. Das funktioniert ja auch mit Frameworks und so Zeugs ganz gut.
Genau. Dass man einfach mal ein bisschen wartet. Das meiste davon ist dann irgendwann wieder weg.
Und, ähm, ja.
Wir können übrigens mal irgendwie noch mal über HTML ... Nee, HTMLX sprechen, weil das jetzt ja grade irgendwie aus mir unbekannten Gründen aufpoppt überall.
Okay, find ich eine gute Idee. Willst du wissen, was ich für den Grund halte?
Warum das überall aufpoppt grade oder was? Mhm. Äh ... ja.
Der Grund ist meines Erachtens, dass die ganzen Single-Page-Application-Codebases mittlerweile einen Legacy-Grad erreicht haben.
Dass die Leute sich denken, boah, das war ja gar nicht mal so gut, lass mal neu machen. Aber wie könnte man's denn anders machen?
Okay. Und deswegen kommen jetzt ja die Multi-Page-Applikationen und was nicht alles.
Deswegen wird das jetzt ja wieder ernsthafter diskutiert.
Und dann fiel das dann mit rein, weil das ist ja irgendwie, hey, das ist ja quasi wie so Knockout.js früher, ne? Mhm.
Ja, mich hat das ein bisschen erinnert an, ähm ...
[1:16:03] Polymer auch so ein bisschen. Weil du ... Also, Polymer ist natürlich ...
Die haben so mehr mit Custom-Elementen gearbeitet. Aber, ähm, so dieses, ähm ...
Also da war's ja auch so, dass du so AJAX-Requests, glaub ich, deklarativ, ähm, oder die Endpunkte da deklariert hast, oder so, mit denen sich die Dinger dann füllen sollten.
Und so ein bisschen ist es da ja auch.
Ja, also da würd ich halt sagen, bei Polymer war das mehr so, da kam's andersrum. Also mehr so die Idee, wir machen jetzt Custom Elements.
Und daraus den Schluss gezogen haben, alles muss sich halt in Custom Elements und damit auch in HTML-Attributen und Co. ausdrücken lassen.
Was jetzt glaube ich nicht unbedingt ein guter Fit ist auf Custom Elements per se.
Aber um so Beziehungen herzustellen zwischen wenn Button-Klick, dann AJAX-Request hier losschießen, wie das das HTMX macht, halt ich das mal für valide, das kann man so machen.
Ich weiß halt nicht, ob das ... Also, das wird einem dann wieder angedreht werden, als irgendwie so die Lösung-TM.
So, schmeißt dein React weg und nimm das HTMX.
Als wär das alles eins zu eins das Gleiche. Ja. Aber ich glaube, das könnte echt so eine Art turbogeladenes jQuery 2.0 sein.
Mhm.
Und ich finde, die Welt kann sowas durchaus gebrauchen. Ja. Ja, ich bin gespannt.
[1:17:26] Ja, lass mal wen finden. Ja. Alles klar. Machen wir. Und das ist jetzt sowieso alles Outro-Gefasel, das nach der Musik kommt, oder?
Genau. Aber kann sein, dass die Sabine es reinschneidet. Vielleicht auch nicht.
Ich finde, das können wir durchaus behalten. Ich glaube, ich habe nichts gesagt, wofür ich mich jetzt unmittelbar canceln lassen müsste.
Aber vielleicht passt das besser irgendwie nach dem ... Genau, die Vorbesprechung haben wir ja nicht aufgenommen.
Dann haben wir zumindest die Nachbesprechung.
Genau, vor der Nachbesprechung ist nach der Vorbesprechung. Genau.
Ja, dann gucken wir mal mit HTMX. Dann ... ich halt mal ausschau nach irgendwie Fachpersonen, die dafür in Frage kämen.
Ich wär da durchaus interessiert dran. Ja. Ja. Ja. All righty. Gut, dann machen wir einen Deckel drauf.
Ich wünsche dir einen schönen Tag. Sollten wir nicht erst hier auf Stop drücken, damit er dann auch die Tracks uplädt?
Ja, das wäre nicht schlecht.